Generally, there are two types of printer drivers—monolithic drivers and table-driven drivers. Monolithic drivers are custom pieces of software code that translate the print job from computer application language to a format readable by a printer. Monolithic drivers require a large amount of software code and thus are costly to develop. Alternatively, table-driven drivers were developed because each driver typically performs a similar set of functions. Although the commands for performing certain functions may be different for various, there is a common set of operations that are accomplished for each print job.
One example of a table-driven driver is the Universal Printer Driver (UNIDRV) provided as part of the WINDOWS™ operating system. A very basic UNIDRV solution can be implemented without writing any code. To control the behavior of the printer, a printer driver solution provides a user-interface (UI) having dialog boxes and property sheets. The UI allows a user to control how output appears on the printed page and provides the user with printing options, such as paper sizes that are supported by the printer. Typically, printer manufacturers control the look and feel of the UI. Although the UI supplied with UNIDRV, known as the “treeview,” can be customized to some extent, the overall look and feel of the UI can not be readily manipulated. As shown in FIG. 1A, the treeview is a structured list of settings that aligns the settings horizontally at predetermined positions. Another limitation of the UNIDRV is that is does not filter the options that are shown in the treeview. For example, all paper formats and sizes are shown in the treeview, even if the connected printer does not actually supports those formats and sizes. For example, the option to print on A4 paper is provided to the user even if the printer cannot print on A4 paper.
Another limitation of the UNIDRV is the lack of the ability to provide color management dependant upon whether text or graphics is being printed. If the line being printed contains both text and graphics, UNIDRV prints all black pixels using a combination of CMYK instead of using pure black to print the text portions of the line. Similarly, UNIDRV only allows a single half-tone screen for each line of printing. If the line contains both text and graphics, a smooth half-tone screen is applied to all pixels, even though it is desirable to apply a detail half-tone screen to the text and vector graphics portions of the print job.
Additionally, most commercial printers are shipped with a resident hypertext transport protocol (HTTP) server. This server provides printer status information and requires a complex USBDOT4 protocol used in conjunction with a custom I/O driver resident on both the client computer and the printer. Serving HTML pages through this interface increases the amount of traffic through the interface, which, in turn, slows responsiveness.
Therefore, a need exists for an extension of the UNIDRV that allows for the customization of the UI, facilitates the ability to control the options presented in the UI, that provides various printing enhancement features such as multiple forms of color management and the use of multiple half-tone screens on a pixel-by-pixel basis, and that provides printer status information.